Alexander是社区的主要贡献者和代码提交者，致力于JSON、索引等数据库新特性的工作。

PostgreSQL是第一个可以使开发人员使用非原子数据类型完成app开发的关系型数据库。Postgres中的JSONB对于现代应用程序开发人员来说是很有吸引力的特性，他们希望在不牺牲强大的一致性和使用所有经验证的关系技术能力的情况下处理JSON文件。最后，SQL组织认可了NoSQL并发布了新的SQL-2016标准，其中包括SQL/JSON数据模型和路径语言的规范，以及用于存储、发布和查询JSON数据的SQL命令。我们将介绍在PostgreSQL中查询json的路径语言json path的实现，并讨论可能的扩展，例如非原子数据的新索引模式，它只允许索引指定的部分，例如jsonb中与给定的jsonpath[s]匹配到操作类的部分。

Bruce Momjian是PostgreSQL社区核心贡献者和代码提交者。

数据库分片涉及到将数据库内容分布在多个服务器上，每个服务器只包含数据库的一部分。虽然可以垂直扩展Postgres，也可以跨多个服务器扩展只读工作负载，但是只有切分才允许多服务器读写扩展。

本演示将介绍切分的优点和未来的Postgres切分实现需求，包括外部数据包装增强、并行性以及全局快照和事务控制。

Christophe Pettus是PostgreSQL社区贡献者。

数据库系统的性能不仅是以线性方式损失。他们通常达在达到一个点后，非常迅速的性能降低。

本文讨论了PostgreSQL中最常见的一些性能变化的 “不连续性”，以及如何为它们计划和缓解它们。

康斯坦丁在PostgreSQL（PostgreSQL 7.4）的职业生涯开始于图拉分校办公室“Reprography研究所”（www.reprograf.ru），2009年担任高级编程专家。2013年，康斯坦丁加入了Ingate团队的职位：开发人员 系统体系结构部门，数据库专家 - 将现有项目从Microsoft SQL Server迁移到PostgreSQL，设置数据库备份，提供容错功能，以及作为DBA专家来维护Microsoft SQL Server 2008r2 / 2012服务器上的项目。 2014年，康斯坦丁来到俄罗斯最大的分类网站Avito，并成为世界第二大分类网站（仅次于美国Craigslist）。 Konstantin是数据库开发团队的领导者，负责在数据库环境中开发体系结构，并负责开发人员使用PostgreSQL进行培训和咨询。

在本报告中，我想分享Avito在不同情况下使用备机的经验：包括基于复制的横向扩展中的问题和解决方案，我们的解决方案实现可以避免正在进行流复制时的读取在使用高请求率的备用文件，应用DDL、从存档中接收WAL文件以及在生产中使用少量备用文件以及在它们之间路由查询的技术时，突出可能出现的问题的案例。DRP灾难恢复计划-在崩溃后将备用/备用文件与存档文件同步。

我五年前加入了Avito 团队。现在它是世界第二大分类网站，其广告存储在PostgreSQL数据库中。本演示的一部分旨在描述在运行由PostgreSQL支持的应用程序时将读取操作卸载到只读副本时的基本技术。对于可扩展性来说，这是一个相当好的高影响和低工作量的胜利，但并非没有挑战。可能会出现过时的读取。另一部分是关于许多人不知道的几个陷阱，而其他人只是接受了风险。

当您使用高请求率的备用文件/应用DDL/从存档中接收WAL文件/在主崩溃后提升一个备用文件而不保存存档和其他备用文件的一致性时，可能会发生这些问题。

在不断使用物理复制的多年中，我们积累了丰富的经验，重新考虑了很多，实施了我们自己的解决方案，在分布式数据处理系统崩溃的情况下归档和恢复命令以及灾难恢复计划。

所有这些努力及其成果都值得与以计划和推进PostgreSQL的企业使用分享。

Corey Huinker作为Illuminated Computing的所有者，Paul在波特兰地区及其他地区从事软件开发和咨询工作。 他在8岁时开始编写Tandy 1000编程，此后一直无法停止。 自8.3天以来，他一直在使用Postgres，并且很自豪能够为该项目做出一个（非常适度的）贡献。 他对使用时态数据库跟踪历史特别感兴趣。

时序数据库允许您记录历史：要么是数据库的历史（表过去的查询结果），要么是事物本身的历史（它过去是什么），要么同时记录两者。时序数据库的理论可以追溯到90年代，但是标准化只是从SQL:2011中的一些适度建议开始的，并且数据库产品（包括Postgres）仍然缺少主要功能。本文将讨论时序表的结构、查询和更新方式、SQL:2011提供的（不提供）、Postgres已经具备的功能以及有待构建的内容。

存在许多跟踪数据库更改的解决方案，例如用于审阅或遵从性。通常，它们使用触发器在单独的模式中记录更改，更好的方法还允许您轻松查询数据库在特定日期所存储的内容。另一方面，如果你想记录一个事物本身的历史，那么就没有什么解决方案可用，问题就更复杂了。历史维度不能由触发器自动构建，但用户需要一种方法来编辑旧的“版本”。他们不仅想问“从时间t开始”这样的问题，还想通过过滤、投影和加入来保存历史变化。如果没有RDBMS的一流支持，这种功能就很难构建。

Kuntal ghosh是EnterpriseDB的高级软件工程师，正在使用开源PostgreSQL和EDB的Postgres Plus Advanced Server。 他正在研究各种PostgreSQL研究和开发项目。

在PostgreSQL中，元组锁定是维护数据库一致性的重要机制。但是，当前的元组锁定系统（也称为多事务锁定系统）有一些局限性，例如，元组上的每个新锁定器都将现有的锁定器与自身结合在一起，并在pgmulixact关系中创建一个新的多事务条目，从而增加pgmulixact关系的大小。此外，为每个多事务条目维护一个32位计数器多事务ID，这需要有效的老化管理、存储清理和环绕处理。在EnterpriseDB中，作为新的存储引擎“zheap”的一部分，我们重新设计了多锁存器机制，以减少上述限制的影响

由于zheap是一个基于撤销的存储，所以它将每个储物柜的锁定信息存储在单独的撤销记录中。任何想要锁定元组的事务，它都会遍历与存储该元组的页面对应的所有撤消记录，并收集所有锁存器。因为撤销记录最终会被丢弃，“zheap”多储物柜机制不需要任何单独的存储清理管理。在本文中，我们将详细介绍ZEAP中锁紧机构的设计，并讨论如何在一些案例研究的指导下避免当前多轴系统的一些局限性。

Andrey Borodin是软件工程师、计算机科学家、Yandex的开发人员、博士、乌拉尔联邦大学的联合教授、Octonica公司的联合创始人。

Odyssey是为高负载环境设计的新PostgreSQL连接池。它可以通过指定附加工作线程的数量来显著地扩展处理性能。这允许通过共享全局服务器连接池来提高SSL/TLS性能并提供更均衡的池控制。

Odyssey是PostgreSQL连接池，从头开始设计，提供多线程处理。每个工作线程负责验证和代理客户机到服务器和服务器到客户机的请求。所有工作线程都共享全局服务器连接池。

它跟踪事务状态，如果发生意外的客户端断开连接，则可以在将服务器连接放回服务器池以便重用之前，发出自动取消并回滚放弃的事务。Odyssey允许将连接池定义为一对数据库和用户。每个定义的池可以有单独的身份验证、池模式和限制设置。

Odyssey有一个复杂的异步多线程架构，由定制的协同引擎驱动。其中一个主要目标是使新开发人员能够理解代码库，并使体系结构易于扩展以用于未来的开发。讨论期间将介绍协程设计背后的想法和更详细的功能概述。

Masahiko Sawada是日本NTT的软件工程师，提供数据库技术支持。他的主要工作方向是数据库安全性，交易，复制和补丁审查。

数据加密是保护数据不受窃听、盗窃等威胁的有力手段之一。存储信用卡号、用户个人信息等机密信息是非常重要的，同时，PCI DSS、GDPR等各种数据保护标准和法规也有要求。

我们一直在研究如何通过为PostgreSQL实现内置的透明数据加密来提高PostgreSQL的安全性。在本文中，我将首先介绍一些关于数据库加密的研究。然后，基于我们的解决方案，我将提供一些实现透明数据加密的内部细节以及POC的性能评估结果。它还包括强大的加密密钥管理，这是数据加密的另一个重要功能。

各种数据保护标准和法规（如PCI DSS、GDPR等）要求数据加密。PostgreSQL中存储的数据有加密方法，如PGCrypto和使用luks的文件系统级加密。但是，它们不满足用户所需的数据库加密的以下属性和实际中的一些安全标准：

■ 透明数据加密（TDE）

■ 最小化性能影响

■ 平台独立性

我们一直在研究PostgreSQL的内置数据库加密。我们的解决方案包括每个表空间透明的数据加密，同时保持最小化的性能影响。我们制作了一个概念验证代码来评估我们的解决方案的可用性和对性能的影响。

在本文中，我将讨论机密信息保护的原则和数据库加密方法。然后，我将提供PostgreSQL内置透明数据加密的一些内部细节和评估结果。它还包括强大的加密密钥管理，这是数据加密的另一个重要功能。

Haribabu Kommi是PostgreSQL社区贡献者。

PostgreSQL与许多其他RDBMS不同，只支持单一类型的表。在本文中，我们将讨论可插拔存储的需求及其在未来的PostgreSQL版本中的好处和可插拔存储的下一步。

可插拔存储是PostgreSQL开发中的热门课题。关于我们是否需要他们的激烈辩论已经结束。

怀疑可插拔存储可能是不一致行为的根源。

可以广泛理解的是，至少在替代MVCC实现中需要可插拔存储。

这是可插拔存储接口设计的一个方向。

本次演讲将涉及可插拔存储接口概述；实现该接口所需的PostgreSQL内核的变更；可插拔存储的当前和潜在实现，包括具有撤消日志和内存引擎的堆；补丁集的当前状态及其预期提交时间接口的进一步开发，允许在可插拔存储中有更多的可能性（列存、索引组织、LSM等）等内容。

Pavlo：Cybertec的PostgreSQL专家和开发人员。有17年的Postgres工作经验。

本演讲是关于现在社区如何处理PG的国际化和本地化。我们可以通过在线平台扩展我们的翻译。这对于现在的过程是无害的，它可以和现在的工具一起使用，比如Poedit、Kbabel。 现在我们正在使用https://babel.postgresql.org/来管理翻译，但是我在Transifex.com和Crowdin.com等在线翻译工具方面有着极好的经验。它对于开源项目是免费的。我已经创建了PostgreSQL组织

https://crowdin.com/project/postgresql

通过在线翻译，你可以让社区里的信任加入进来。例如，在我的指导下，高中青少年正在进行新的乌克兰语翻译。但我们也为学生提供了GSOC项目。翻译很容易指导，也很有趣。

Yugo Nagata是日本SRA OSS公司的总工程师，负责与PostgreSQL相关的研发工作。在2011年加入SRA OSS，Inc。日本之后，他参与了PostgSQL的集群工具Pgpool-II的开发，他对PostgreSQL开发的第一个贡献是在2012年。除了开发之外，他还经历了技术支持，咨询和教育。 PostgreSQL和其他开源软件。 日本北海道大学工学学士和信息科学硕士。

增量视图维护（incremental view maintenance，IVM）是一种维护物化视图的技术，它只计算和应用实体化视图的增量更改，以提高刷新效率，但这还没有在PostgreSQL上实现。在本文中，我们将讨论实现IVM的必要性以及关于PostgreSQL上第一个版本的IVM实现的想法。

PostgreSQL从9.3开始支持物化视图。此功能用于通过存储指定查询的结果来加速查询评估。物化视图的一个问题是它的维护。当下属基础关系更新时，必须更新具体化视图。

在本文中，在介绍了一些关于IVM的研究和讨论之后，包括我们的POC（概念验证）实现，我们将讨论在PostgreSQL上实现这一点的必要性。例如，我们必须决定如何提取基表上的更改，如何计算要应用于具体化视图的增量，何时维护具体化视图，等等。另外，我将展示关于PostgreSQL上IVM实现的第一个版本的想法。

CB Bohn是一位经验丰富的数据专家，最近在Etsy的数据工程领域工作了11年。

PipelineDB是一个PostgreSQL扩展，支持时间序列聚合。PipelineDB使用一种称为“连续视图”的新型关系，将PostgreSQL实用程序扩展到流分析领域。连续视图类似于传统视图，只是它可以从数据流而不是表中获取数据。当流数据到达时，视图的值会不断更新。这在点击流数据分析、系统监控和A/B测试等方面有着广泛的应用。连续视图可以构建为在整个数据流上或在滑动窗口上操作。PostgreSQL分析函数的所有功能都可以在连续视图中使用，还可以使用流式数据分析特有的其他函数。

PipelineDB将PostgreSQL转换为一种非常可行且功能强大的流式分析技术。这是Kafka Streams的另一种选择，它在SQL中构造了流水线式B流分析的巨大优势，而后者则需要Java编码体验。数据分析师通常生活在一个SQL世界中——这是他们所知道的。StudioDB授权分析人员通过SQL构建自己的流分析，而不是依赖Java工程师对逻辑进行编码，使其规模化。PipelineDB还允许组织将其现有的PostgreSQL管理资源利用到其流式分析基础架构中，这可以显著节省成本。

这是一个介绍性的演讲，但是参加会议的人会对pipelinedb是什么、它是如何工作的以及为什么要考虑它有一个很好的理解。

流分析正在成为数据策略的重要组成部分。PipelineDB将PostgreSQL变成了唯一能够在流分析中提供真正实用性的RDBMS。任何与PostgreSQL有关的人，在一个正在考虑其流分析策略的组织中，都将从这次演讲中获益。

AdamWołk是Fudo Security的软件开发人员和OpenBSD开发人员。

Mariusz Zaborski是Fudo Security的质量保证和开发经理。 Mariusz的主要兴趣领域是操作系统安全性和低级编程。 他也是FreeBSD的提交者。

有些情况下，现有的数据库机制无法提供足够的方法来确定正在执行的工作。这种情况的一个例子是由于快速更新机制和查询计划计算缓慢而导致的GIN索引重建。由于错误选择了系统计时器。在dtrace的帮助下，我们将了解Postgres的内部结构，并演示系统管理员如何清楚地识别挂起插入的根本原因以及查询计划的计算速度慢。dtrace是由Sun Microsystem创建的动态跟踪框架，可在FreeBSD、NetBSD和MacOS中使用。d trace是一个强大的工具，它允许软件开发人员和管理员使用高级脚本语言-d测量性能并跟踪他们的应用程序。

Gin在postgres中指的是一种倒排索引，而不是一种酒。广义的意思是索引不知道它加速了哪个操作。当同一个键出现在多个堆中时，必须进行多个搜索/插入在大容量插入过程中成本高昂，因此开发了一个快速更新功能，可以维护延迟索引重建的待处理条目列表。通常，挂起的列表通过真空过程与主目录树合并，但在其他情况下也可能发生。目前，PostgreSQL数据库缺乏一种机制，允许DBA知道这种情况发生的确切时间和时间。这可能导致看起来像是挂着的插入，DBA不知道是什么导致了暂停。使用dtrace，我们可以精确地显示重建发生的时间、花费的时间以及DBA如何在D中编写脚本，从而为将来扩展他的工具箱——所有这些都不需要重建数据库。